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MULTICAST-ENABLED ADDRESS 
RESOLUTION PROTOCOL (ME-ARP) 

FIELD OF THE INVENTION 

5 

This invention relates to a scalable and sender-less solution to build Virtual Private 
LAN Segments (VPLS) based on a multicast enabled IP backbone and more particularly to 
a Multicast-Enabled Address Resolution Protocol (ME-ARP). 

! 0 BACKGROUND OF THE INVENTION 

The popularity of the Internet is driving requirements for secure aijd segregated IP 
interconnection of remote sices. One solution is to use the underlying network supporting 
virtual connections i.e. Frame Relay or ATK-I. These virtual connections can be separated 

i5 by provisioning to form a Virtual Private Network which is Layer 3 protocol transparent. 
However if the underlying network is IP itself, as is the case with the Internet then IP 
tusmels can be used to interconnect two or more sites. Any other known layer 2 VTN 
(Virtual Private Network) solution used in the prior an requires a centralized server where 
all CPE (Customer Premises Equipment) aud IP devices have to be statically or 

20 dynamically registered, like LANE (Local- Area-Network Emulation), NHRP (Next-Hop- 
Routing-Protocol) or Classical IP, 

A need exists for building IP based virtual private LAN segments (sharing one IP 
subnet) with connpiete transparency regarding TCP/IP, site-independent CPE 
25 configuration and with dynamic stateless turmeis to optimally forward unicast traffic based 
on routiBg and policy per VTLS. VPLS with different Identifiers can use overlapping IP 
subnets. With the method of the present invention, a centralized server or a list of CPE 
devices configtired for each VTN is nor required. 

30 SUMMARY OF THE IN^TNTION 

1 
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One aspect of the present mveniion is to provide a scalable and ser^-er-less solution 
to build Vsnual Private LAN Segments fVPLS). 

Another aspect of the present invention is to provide a MiiUicast-Enabied Address 
Resolution Protocol (ME-ARI^). This invention allows the building of independent IP 
bjsed Virtual Private LAN segments (VPLS) over a multicast enabled IP backbone usjng 
stateless tunnels and optimal VPLS traffic fomarding. Each VPLS has an assocrated IP 
subnet which ss independent from other VPLS or the underlying IP backbone itself. Each 
Customer Premises Equipment (CPE) devsce needs only to be configtjred with a VPLS 
identifier and its serving IP subnet per VPLS designated interface. In addition, each end 
station connected to a Physical LAN Segment (PLS) does not need to be modified in order 
to be a member of the VPLS, No other configuratiori parameters e.g. list of CPE devices, 
their logical or physical locations nor their IP addresses are required. The unique 
invention is ME-AKP (Multicast Enabled Address Resolution Proiocol) including the 
creation of constructed lower layer address based on VPN (Virtual Private Network) Id 
and tunnel endpoint. Advantages provided by the method of the present invention 
include: 

a) separation of customer IP address space from either the service provider or 
another customer determined by policy not to be in the same virtual 
private network (VPN); 

b) capability for a remote site to belong to one or more VPN as long as the 
VPN policy allows. To provide support for IPv4 based applications at this 
point; 

c) transparent or Routed VPN's (by tjse of external routers) can be 
constructed independently or combined with this architecture; 

d) due to the use of an underlying IP multicast network to forward VPN 
broadcast traffic in this solution ,there is no need to provide address or 
broadcast servers; and 

e) VPN traffic forwarding is achieved via stateless and optionally secured 
tunnels which are optimally routed using the underlying IP network 
backbone routing architecture. 2 



SUBSTITUTE SHEET (MULE 26) 



wo 00/56ei8 



BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. la is a block diagram iilusrrating a physicai view of a Vmuzl Private LAN 
Segment (VPLS) network for use wkh the present s) 



FIG. lb is a diagram liiustming a logical view of the network of FIG. la or as 
d be seen from the custonn 



FIG. 2a illustrates a packet format corresponding to an IPsec Authenticadon 
(AH) encapsulation with authentication; 



FIG. 2b iilusirates a packet format corresponding to an IPsec Encapsulating 
Security Payioad (ESP) ^'ith amhemication privacy; 

FIG. .3 illustrates a standard ARP packet format on Ethernet; 

FIG. 4 IS a block diagram of a IP Backbone network for iUustrating the ME-ARP 
request/reply packet flow according to the pres 



Fig. 5 is a block diagram illustrating the transfer of ME-AKP packet information 
between a first and second end station according to the method of the present invention; 
and 

Fig, 6 is a table illustming the content of the ARP tables at various point during 
the transfer of ME-.ARP packet informanon. 

Similar i-eferences are tssed in different figures to denote similar components. 

In order to facilitate the description of the invention, the following abbreviations 
have been used. The terminology used in this doctiment is based on 
proposed by rhe Internet Engineers Task Force (IETF). 



GET Core Based Tree Multicast Routing Protocol 
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CPE 


Customer Premises Equipment 


DVMRP 


Oist^icc' Vector Muiticiisting Routing I' 




Generic Routing Encapsulation 


IGMP 


Internet Group Management Protocol 


LAN 


•Locai Area Network 


MOSPF 


Mukkast extensions for Open Shortest 


PA 


Provider A.ddress 


PIM 


Protocol independent Multicast 


PLS 


Physical LAN Segment 


VPN 


Virtual Private Network 


VPLS 


Vinual Private LAN 


UVIP 


Unnumbered VPN Internet Protocol 



The terra "Client Address" (CA) space or network ranges is used to describe the IP 
1 5 address space used by each VPN customer. 

The term "Customer Premises Equipment" (CPE) defines an edge device (e.g., 
router, etc.), Rsliy managed by the provider, connecting a customers PLS to its VPN. 

20 The term "Provider Addres.s" (PA) space or network ranges is used to de,icribe the 

provider aliocaEed IP addresses in his IP backbone, (e.g., Tunnel endpoint.s have an adtlress 
assigned out of the PA range). 

The tem "Physical LAN Segment" (PLS) is used in this document to describe a 
25 broadcast domaitx, like a shared or switched ethemet segment, conneaing hosts, servers 
and routers at each site. Without the ms of a YPN technoiogj, the scope of these PLS is 
limited per site. 

A Virtual Private LAN Segment (V-TLS) is the emulation of s. LAN segment using 
30 Internet facilities. A VPLS can be used to provide what is sometimes known as a 

transparent LAN service, which can be used to interconnect mtiltiple CPE nodes, it cm be 
seen as a pure layer 2 bridged VPN solution. 

The term virtual private networks (VPN") is widely used as a common description 
35 for any kind of network built over another network with limited scope. 

4 
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The tern) "Unnumbered VPN fP" (UVIP) interface is used m VPLS to describe the 
tunnel endpoim connecting a PLS on a first site with ail otber PLS per VPN. In the scope 
of the custoiTier's PL.S, this interface doesn't need to have an IP address assigned to for^v-ard 
traffic (VPLS is a layer 2 VPN solution). The tunnel endpomt itself must have an IP 
5 " address assigned, out of the providers address space. 

DETAILED DESCRIPTION OF THE IN\nENTION 

In order to take advantage of all the features of the present invention, it is assumed 
!0 that the providers of IP backbone services are IP multicast capable. Similarly, k is assumed 
that CPE devices are able to join a multicast group using IGMP. It is not a requirement 
that all routers in the backbone have multicast capabilities. It is possible to interconnect 
the CPE devices via a partially meshed or "star-like" multicast backbone, built usmg a mix 
of multicast routing protocols and tunnels to interconnect multicast islands. IP multicast is 
15 used to forward broadcast and muidcast traffic and for IP address resolution, but not for 
forwarding of unicast traffic. 

Referring now to Fig. la, we have shown the physical view or service provider's 
view of a Vsrtual PnvaEe LAN Segment (VTLS). The IP backbone 10 and CPE devices 11, 
20 12, 13 and 14 are managed and typicaJiy owned by the service p-f-ovider. CPE devices 11-14 
are typically comprised of routers, whereas each PLS is typically comprised of several IP 
capable devices such as end stations (ESI, ES2, etc.) 

Fig. lb is a diagram iUu-wrating a logical view of the network of Fig. la or as would 
25 be seen from the customer's perspective. Whereas in Fig. la the CPE devices are visible 
from the provider's perspective, LAN segments are transparent to the customers as 
illustrated in Fig. lb. Similarly, CPE devices which are seen by the service provider are 
invisible to the ctjstomer. 

30 Stateless turmels or links are used in CPE (Customer Premises Equipment) between 

connected sites. The remote liinnei endpoint address information is directly mapped into 
the link layer address. ME-ARP is used for IP address resolution inside a WLS. As a 
result, VTN connected IP devices will keep all relevant information about the destination 
tunnel endpoint and VPN membership in their own address resolution (ARP) table. 
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Special unnufnbered IP LAN interfaces will generate the link layer address based on a 
configured VPN idenufier and dynamically learned tunnel endposnts (via ME~ARP). 

Again, as illustrated in Fig. la and lb, a VPLS can span two or more sites, with all 
5 IP devices sharing ihe same IP subnet. The IP address and mask are chosen by the 
customer without any restnctions m relation to the- provider or other customers. The 
CPE devices, managed by the provider, are transparent to the customer. This type of layer 
2 VPN solution possesses the following benefits for the customer: 

■ 0 + Transparency. No iP addresses must be given to the provider; 

+ Flat IP subnet. The VPN can be seen as a VTLS, with transparent support 
for broadcast protocols like DHCP/BOOTP pynamic Host 
Configuration Protocol / BOOTsirap Protocol), Netbios/IP etc; and 

i5 

H- Broadcast and Multicast support. The customer can extend the \TN with 
their own routers and run Miy routing protocol over the VPN without ajiy 
coordination with the provider. 

20 Each VPLS has a provider wide unique IP multicast address assigned. A UVTP 

interface of a CPE device, shown at reference numerals 15, 16, 17 and 18, configured for a 
panicuiar VPLS, will join the VTN's mukicase group by using IGMP. All broadcast traffic 
is then encapsulated and forwarded to the VPN's IF multicast address. There is therefore 
no need for a central database to keep track of all U VIP interfaces joining a customer's 

25 VPN. This is handled by the IP multicast membership. 

In order to forward IP imicast traffic, an enhanced version of pro3£>' ARP is used. 
The differences from the standard proxy ARP are: 

30 a) all ARP requests matching the ctjstomers iP stjbnet are encapsulated and 

forwarded to all \TN members by sending them to the VPN's IP multicast 
addres.s. Note: The CPE device cannot determine, if axs IP device is 
connected to the local physical segment or not. 

35 b) a forwarded ARP request, after decapstilatioo, will replace the source 

hardware address (MAC, Media-Access-Controi or physical Address) not 
6 
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v/ith the routers own interface MAC address, but by a caiculateci address 
coiitairung the tunnel source IP address, an interface unique VPN Id (e.g. 
VPN instance Id) and a CPE Id (to avoid loops in case of CPE 

5 

The result of this "multicast enhanced ARP" (ME-ARP) process is that the 
customers IP devkes will keep all relevant information about the destination tunnel 
endpoint and VPN membership in their ARP table. There is no overhead involved, if 
compared to a real physical IP subnet. 

!0 

Unique VPN Identifier 

Each VPN has a unique identifier assigned. For VPLS built of more than two 
physically separated sites this is a valid IF multicast address. As each VPN has a unique IP 
! 5 multicast Id assigned, IGMP and any rriukicast capable routing protocol (DVMRP 
(Distance Vector Multicast Routing Protocol), MOSPF (Multicast Open Shortest Path 
First), PIM (Protocol Independent Multicast), are used by a configured IP VPN interface 
connecting a Physical Segment to join the VPNs multica,st group. 



7 
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Individual CPE devices are configured as io'iiows: 

Based on the VPLS membership usmg IP multicast, there is rio need for a central 
VPN membership database or protocol to distribute this informarion. k is encjgh to 
5 configure a new VPN member (physical segment) m the connecting CPE device. The 

uiinial information is configured per UVIP (Unnumbered VPN IP) interface: 

VPN IP multicast Id; 

IP Network/Mask. Assigned by the customer from the Client Address 
(CA) space. This information is used to determine the correct VPN, based 
on either source or de.stination IP address. This is important to support 
muki-neExing on the same physical interface with many VPNs; 

Tunnel IP address. This address frorn the Provider Address (PA) space is 
used to forward VPN traffic over the IP backbone to the correct tunnel 
end-point (bound lo a VPN interface). The VPN identifier in each 
encapsulated packet can be used to identify the correct logical UVIP 
interface inside the CPE device; 

MAC calculation algorithm. This optional, but recommended, 
configuration parameter allows the support of different MAC address 
calculation to prevent possible duplicates. 

25 Referring now to Figs. 2a and 2b, in the preferred embodimenr of the invention, 

depending on the security requirements, three different encapsulation formats can be used: 
without secnrity, with authentication only or with encryption. The encapsulated methods 
are based on-IPsec tunnel mode [RFC24CL..RFC2406]. The IP2 header contains the IP 
source and destination address from the providers address space (tunnel endpoint IP 

30 addresses or address as destination address). The IPl header is the original IP packet 
header. 

In Fig. 2a, we have shown an IPsec AH encapstiiation (with authentication). Fig. 
2b shows an IPsec ESP encapsulation (with auth. privacy). 

35 

8 
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IP multicast and, broadcast packets are encapsulated and tigged with the VPN 
tTJiihicast Id in the SPI field of the IPsec AH/ESP header and For^-arded to the VPN iP 
multicast address (equal to VPN multicast Id). Ail active niejubers of the VPNs miilticasi 
groiip receive the encapsulated packet and forward it to the appropriate VPN's LJVIP 
5 interface. 

Referring now to Figs. 3, we have shown an APJ? Request/Reply packet including 
Ethernet transmission layer. In Fig. 4, we have shown a block diagram of an IP Backbone 
network and in Fig. 5, we have shown a block diagram illustrating the transfer of packet 
10 information between a first and second end station, respectively. 

In operation, with reference to Fig.s. 3, 4, 5 and 6, end station A wants to send an. 
IP packet to end station B on the same logical subnet but connected to different gateways. 
It IS assumed, that the ARP tables 80 and 81 from both end stations are empty. Therefore 

15 end station A sends an ARP request 50 to the ethemet broadcast address 51. CPE A, 

configured with the proper VPN information, checks the source IP address 52 of the ARP 
request packet 50 against its WW interfaces configured on the physical interface. In case 
of a match, it encapsulates the whole, immodified, ARP request 50 into an IPsec packet 55 
including the VPN identifier 56{equals assigned IP multicast address) and for-w^ards packet 

20 55 to the VPN's multicast address 57 using the configured local IP tunnel-endpoinc 58 as 
source address. CPE A also adds a local ARP entry for end station A in its ARP table 72 
for that UVP interface. (CPE A will forward the ARP request, even if end station B is 
conneaed to the same physical network). 

25 All CPEs joining the VPN will receive this encapsulated ARP request, unpack it, 

and forward out the local LTVIP interface with the following modification to the original 
ARP request 55: 

replace the original H"W source address 59 (MAC address from end station A) with 
30 a calculated MAC address containing the tunnel end-point IP address from CPE 

A(=» source address from the received IPsec packet) and an optional interface 
unique VPN Id. 

9 
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This new HW source address 60 Is repkced m the eihernet header .k ^-ell as xn the 
ARl' packet 61. 

CPE B might add an entry to its ARP table 83 for cachiEig. End station B receives 
5 the ARP request 62 and respond to it with a normal ARP reply containing its physical HW 
MAC address 64 as source m the ethernei header and m the AP^P reply packet 65- An ARP 
entry for end station A with the source MAC address from the ARP request is added on 
end station B. The ARP table 81 of end station B now contains an entry tor end station A 
with a constnicted MAC address containing the tunnel-endpoint IP address and VPN Id. 
10 CPE B, configured to listen for constructed MAC addresses, identifies the ARP reply 63 
from end station B by checking the source MAC address 64 as well as the source iP address 
66 (pan of VPN's IP network), encapsulate and forwards the ARP reply 67 directly to the 
addressed tunnel endpoint (extract tunnel endpoint IP address from destination MAC 
address). 

55 

CPE A decapsulates the ARP reply packet 67, checks the destination or target IP 
address 68 and replaces the destination or target MAC address 69 with the address found in 
its local ARP cache, and sends the constructed ARP reply 70 out to end station A on the 
local attached physical LAN segment. In addition, the source MAC address 71 (in the 
20 Ethernet header and ARP packet) is replaced with a constructed MAC address 72 
containing an optional interface locally unique VPN Id and the IP address of CPE B 
(where the AR? reply came from). 

If the ARP table 82 from CPE A does not contain an entry for end station A, then 
25 CPE A will have to send an ARP request out for end station A with end station B's IP 
address before forwarding the ARP reply packet out to end station A. 

Finally, end station A receives the ARP reply packet 70 and builds an entry m its 
ARP table 80 with an entry lor end station B and the MAC address containing the remote 
30 tunnel endpoint IP address and VPN Id. 



10 
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THE im^NTION CLAIMED IS: 



1. A merhod of sending a unicast IP packei from a hrst end station to a second end 
siarion, said first and second end stations being on the same logical subnet and 
connected to different CPEs, comprising: 

receiving said unkast IP packet at a CPE associated with said second end station; 

and 

said CPE associated with said second end station providing said second end station 
with address resolution information containing mapping information berween IP and 
lower layer physical addresses of said first and second end stations, said lower layer physical 
addresses being constructed by said CPE and containing VPN membership and physical 
remote location information such that the constructed lower layer addresses contain 
enough information for said CPE to forward the packet to the correct remote physical 
location. 



2. A method of sending a multicast IP packet from a first end station to naukipie end 
stations, said first and multiple end stations being on the same logical subnet and 
connected to different CPEs, comprising: 



receiving said mukicm IP packet ai each CPE; 
encapsulating said IP multicast packet; and 
forwarding said encapsulated IP multicast packet to a VPN assigi 
wherein said IP multicast packet is received by each CPE which has been 
red to said VPN. 



3. A method as defined in claim 2, wherein said multicast IP packet comprises an IP 



4. A method as defined in claim 2, 
using an IP multicast protocol. 



wherein each of said CPE is configured eo said VPN 
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5. A method as deftned in claim 4, wherein said IP muiticast protocol comprises u>n(r U an 
IGMP, D\'-MRP, MOSPF, MBGP and PIM mukicasi protocols. 



6. A method of sending an IP packet from a first end station to a second end station, 
wherein said first and second end stations are on the same iogical siibnet but connected 
to different CPEs, comprising: 

a) sending from said first end station an ARP request with an ethernet broadcast address; 

b) at a first CPE' associated with said first end station, intercepting said ARP request 
packet and %-erifying the intercepted IP address against a corresponding unnumbered 
virtual packet network (UV) IP interface; 

c) if a match is verified, encapsulating said ARP request into an IPsec packet with a VPN 
identifier; and 

d) forwarding said iPsec packet to a VPN's niukica^t address usmg configured loca! IP 
tunnel-endpoint as a source address. 

7. A method as defined in claim 6, wherein said first CPE fanher adds a local ARP entry 
for said first end station in its ARP table for said UVIP interface. 

8. A method as defined in claim 7, wherein said encapsulated ARP request is received at 
each CPE connected to said VPN. 

9. A method as defined m claim 8, wherein said ARP request is unpacked, modified and 
forwarded out of the local UVIP interface when received at said CPE. 

10. A method as defined in claim 9, wherein said ARP request is modified at each CPE by 
replacing the original HW source address with a calculated MAC address containing 
the tunnel end-poisM IP address from said first CPE and an interface unique VPN Id 
ihm providing a new HW source address to replace in the ethemet header as ^-ell as in 
the ARP packet itself. 



.12 
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Fig. 1b 
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